Electronic commerce cards are frequently used by consumers to make purchases from merchants over the Internet. Electronic commerce cards include credit cards, debit cards, prepaid purchase cards, travel cards, or any other system that can be used instead of cash to purchase goods or services. Electronic commerce cards do not necessarily have to be in the form of a physical card in order for an account associated with an electronic commerce card to be used to conduct transactions. To prevent fraud, electronic commerce card associations and/or issuers have instituted authentication systems to ensure that electronic commerce cards are only used by authorized consumers. One example of an authentication system enables a consumer to associate a password or other identifying information with an electronic commerce card. To make a purchase online, the consumer must provide the password associated or other identifying information with the electronic commerce card. This ensures that the person possessing the electronic commerce card is actually authorized to use the electronic commerce card.
Typical authentication systems use a decentralized, distributed computing model in which information is exchanged between merchants, electronic commerce card issuers and the card association to authenticate consumers. With thousands of card issuers and millions of merchants using a typical card processing system, deploying an authentication system among so many different entities is a difficult task. Additionally, merchants are reluctant to include authentication functions if the authentication system is only supported by a small number of card issuers.
One common problem faced by many authentication systems is how to authenticate a user using a form served from an authentication site managed by an issuer of the payment account while maintaining an online session between the user and a merchant's site.
Original authentication system designs typically used a pop-up window to authenticate the user. These windows were often driven by Javascript with static URLs as a backup. The pop-up window had separate Issuer SSL credentials, and they frequently had no address bar. The merchant would open a pop-up window and direct the pop-up window to open a page served from a server separate from a merchant's server. The pop-up window would contain a form that would be filled out by the user. After the form was completed, a returning POST command instructed the merchant's page to close the pop-up window. The original payment page could then be processed by the merchant to charge the payment account to complete the transaction.
As internet technology developed, pop-up killers began to be used in web browsers, and consequently pop-up methods become difficult to reliably execute. As a result, the design of authentication systems was changed to use a different process. In the new process, the screens that were previously shown using a pop-up window were now presented to the user in place of the merchant's checkout page in the main browser window. As a result, the merchant page's disappeared from the user's view while the online authentication form was being completed. The underlying infrastructure of the authentication system did not have to be significantly changed to accommodate this new process, because the only items in the system that had to be change were the templates used by merchants and issuers to present the authentication pages.
Both of these prior methods presented some problems for merchants and for consumers. In some instances, consumers would feel less secure about the authentication process because they had to navigate away from the merchant's website. As a result, the consumer could no longer see their order and sometimes the consumers would be confused as to why their browser navigated away from the merchant's site. In some instances, if a consumer decided that he or she was uncomfortable with the redirection, the consumer might abandon the order and the merchant might lose a sale. Another problem is that authentication processes that navigate away from the merchant's checkout page can sometimes lose track of the online session tracking the user's transaction. As a result, the user's shopping cart of items could be lost. Consequently, the consumer would have to recreate his or her shopping cart in a new session. A consumer might not want to go through this hassle. The consumer might also lose confidence in the online system. In either case, a sale by the merchant could be lost.
Authentication systems such as the ones just described also frequently involve many different parties managing different pieces of hardware and software that all need to work together to successfully authenticate users. For example, a merchant, a credit card issuer, and a payment processing entity may all operate servers running software that needs to communicate with each other in order to successfully authenticate a user conducting an online transaction. Upgrading a distributed system such as this can sometimes be difficult since no single party controls all of the components that need to be upgraded in order to implement new functionality. Consequently, as components of authentication systems have been modified over time, many of the components of the system are running different versions of the authentication system. Some of these versions may not be fully compatible with each other. It may not be practical to upgrade all components in the authentication system to an appropriate version at the same time, because many of the components of the system are managed by separate entities. One potential problem with the varying versions of components in a deployed authentication system is that if an unsupported authentication protocol is used, then the authentication request may fail somewhere during the authentication process and the user may potentially lose the online session of the user at the merchant's site.
Embodiments of the invention are directed toward solving these and other problems.